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Abstract — The numerous benefits of automatic application 
code generation are widely accepted within the software 
engineering community. A few of these benefits include 
raising the abstraction level of application programming, 
shorter product development time, lower maintenance costs, 
and increased code quality and consistency. Surprisingly, 
code generation concepts have not yet found wide 
acceptance and use in the field of programmable logic 
controller (PLC) software development. 

Software engineers at the NASA Kennedy Space Center 
(KSC) recognized the need for PLC code generation while 
developing their new ground checkout and launch 
processing system. They developed a process and a 
prototype software tool that automatically translates a high- 
level representation or specification of safety critical 
application software into ladder logic that executes on a 
PLC. This process and tool are expected to increase the 
reliability of the PLC code over that which is written 
manually, and may even lower life-cycle costs and shorten 
the development schedule of the new control system at KSC. 

This paper examines the problem domain and discusses the 
process and software tool that were prototyped by the KSC 
software engineers. lf 2 
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1. Introduction 

A New Direction 

NASA Kennedy Space Center (KSC) engineers are 
responsible for pre-launch ground checkout of the Space 
Shuttle and associated ground support equipment (GSE). 
On January 14, 2004, the President of the United States 
announced a new vision for space exploration which 
changed NASA’s goals from low earth orbit operations to 
lunar operations and beyond [1]. In response to the 
presidential announcement, NASA formulated what is called 
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the Constellation program to develop a new generation of 
spacecraft and infrastructure for return to the Moon [2]. A 
concept image of the new spacecraft is shown in Figure 1. 
At KSC, where these new space vehicles will be launched, a 
new ground checkout and launch processing system is 
currently being developed in support of this effort. 



Figure 1 - Artists concept of NASA’s next-generation 
launch vehicle systems. 

Image credit: www.nasa.gov 


Many large and complex systems that have been 
implemented by NASA in the past, including previous 
ground checkout and launch processing systems, contained 
functionality or performance requirements and specifications 
that forced custom solutions. As software processes and 
technologies have matured, commercial off the shelf 
(COTS) hardware and software components have become 
more reliable and provide higher performance. Thus, NASA 
expects to save development schedule and cost by 
integrating various COTS solutions together in order to 
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Figure 2 - Simplified Architecture of KSC’s Launch Control System (LCS). 

Rocket concept image credit: www.nasa.gov 


implement large and complex systems. COTS solutions can 
generally offer significant life-cycle cost savings. 2 3 

A simplified high level architecture of the new ground 
checkout and launch processing system is shown in Figure 2. 
This system is called the Launch Control System or LCS. 
All the computer hardware in the LCS is planned to be 
COTS, including Industrial Controllers or PLCs that are 
connected to the sensors and end items out in the field. A 
significant portion of the software in the LCS is also planned 
to be COTS, with only small adapter software modules that 
must be developed in order to interface between the various 
COTS software products. 

PLCs are basically environmentally ruggedized computers 
that are specifically designed to automate or control a 
process in a factory or plant. PLCs are commonly 
distributed throughout a factory or plant near the motors, 
valves, heaters, etc. they are controlling and near the sensors 
from which they are reading values. Control logic or control 
software typically executes in a PLC to read data or state 
values from input channels, and to control output channels 
accordingly. KSC is not technically a factory or plant, but it 
is an industrial type of environment that is well suited for 
industrial (e.g., PLC) control of end items located in the 
field. 
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In the launch vehicle and spacecraft processing domain the 
control logic in the PLCs that monitors and controls high 
energy equipment or machines, such as pressurized fuel 
tanks, is categorized as safety critical. A safety critical 
component or system is defined as one whose failure can 
cause injury or death. 

Application Software 

Application software is the high level layer of computer 
software that the end user actually interacts with. It allows 
the user to perform specific and productive tasks on the 
computer. Some common examples of application software 
are word processors, database programs, and media players. 
Application software is usually contrasted with system 
software which is the low level layer that interacts directly 
with the computer at a very basic level (e.g., the hardware 
level, the driver level). 

In the LCS, application software is the set of software 
programs conceived, written, and executed by the user that 
is intended to monitor specific end item measurements and 
user inputs and use that information to control the user’s 
remote system located in the field. The LCS architecture 
allows application software functionality to be distributed 
between an application server in the control room and the 
PLCs out in the field. The LCS will likely distribute the 
time-critical closed loop control functionality and the low 
level end item command and response functionality in the 
field-located PLCs and house the higher level supervisory 
control and sequencing functionality in the application 
servers located in the control room. 
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Figure 3 shows a typical example of application software 
source code 4 that might be found in the existing legacy 
ground processing system at KSC. This small portion of 
code, written in a custom high level test procedure language 
called Ground Operations Aerospace Language (GOAL) [3], 
commands a valve to the open state and then looks for the 
appropriate valve position indications within the appropriate 
time constraints. 

$ SEND PRIMARY OPEN COMMAND $ 

TURN ON <VLVl_PRI_OPEN_CMD>; 

$ DELAYS UP TO $ SEC FOR INDICATION OP MOTION. STEP 20 

LOOPS TO STEP 10 UNTIL CLOSED INDICATOR TURNS OFF OR 
a SEC PASSES. $ 

READ <GMT> AND SAVE AS (GMT1); 

STEP 10 READ <GMT> AND SAVE AS (GMT2) ; 

LET (VLVTM) = {GMT2 ) - (GMT1) ; 

5 ADD 24 HOURS IP DAY WRAPS $ 

IF (VLVTM) IS LESS THAN 0.0 SEC, 

LET (VLVTM) = {VLVTM) + 06400 SEC; 

IF (VLVTM) IS LESS THAN OR EQUAL TO 9 SEC 
THEN GO 'TO STEP 20; 

$ ERROR MESSAGE $ 

RECORD <GMT> , 

TEXT ( V ALVEI INITIAL MOTION GREATER ) , 

TEXT OMAN S SEC) TO <PAGE-A> YELLOW TO <CNSL-PP>; 

$ OPEN VALVE 1 USING SECONDARY COMMAND & VIEW SECONDARY 

INDICATORS $ 

PERFORM PROGRAM (OpenValvelSecondary ) ; 

GO TO STEP 100; $ DONE $ 

STEP 20 VERIFY <VLVl_PRI_CLOSED_IND> IS OFF 
ELSE GO TO STEP 10; 

$ DELAYS UP TO 26 SEC FOR INDICATION OF MOTION COMPLETE. 

STEP 40 LOOPS TO STEP 30 UNTIL OPEN INDICATOR TURNS 
ON OR 26 SEC PASSES. $ 

STEP 30 READ <GMT> AND SAVE AS (GMT2) ; 

LET (VLVTM) = (GMT 2 ) - (GMT1) ; 

$ ADD 24 HOURS IP DAY WRAPS $ 

IF (VLVTM) IS LESS THAN 0.0 SEC, 

LET (VLVTM) = (VLVTM) ♦ 86400 SEC; 

IP (VLVTM) IS LESS THAN OR EQUAL TO 26 SEC 
THEN GO TO STEP 40; 

$ ERROR MESSAGE $ 

RECORD <GMT>, 

TEXT ( VALVE 1 OPEN TIME EXCEEDED LIMIT) 

TO <PAGE-A> YELLOW TO <CNSL-PP>; 

$ OPEN VALVE 1 USING SECONDARY COMMAND AND 

VIEW SECONDARY INDICATORS $ 

PERFORM PROGRAM (OpenValvelSecondary) ; 

GO TO STEP 100; $ DONE $ 

STEP 40 VERIFY <VLVl_PRI_OPEN_IND> IS ON 
ELSE GO TO STEP 30; 

$ SUCCESS MESSAGE $ 

STEP 50 RECORD <GMT>, 

TEXT ( VALVE 1 OPEN TIME IS ) , (VLVTM) 

TO <PAGE-B» TO <CNSL-PP>; 

STEP 100 TERMINATE; 

Figure 3 - Typical example of existing legacy application 
software source code 

It is evident from the above code example that software 
programming skills are necessary to write application 
software in the existing legacy ground launch processing 
system at KSC. This necessity led to the formation of a 
group of programmers at KSC that specifically takes 
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requirements from ground and flight system users and writes 
the application software code. Hiring and maintaining a 
group of dedicated application software programmers was 
chosen over the option of training all the ground and flight 
system users to simultaneously be software developers. But 
this decision has turned out to be quite costly over the total 
life-cycle of the legacy control system so alternative 
processes are being investigated for the LCS. 

A Language Of Their Own 

The developers of the LCS are investigating processes and 
tools that will allow non programmers (i.e., system 
engineers, domain experts and end users who are not 
software savvy) to write safety critical control applications 
using a high level representation or format. This high level 
representation is actually considered a “model” of the 
control system from the perspective of the Model-Driven 
Software Development (MDSD) discipline [4]. MDSD 
uses domain-specific abstractions or domain-specific 
languages to formulate the model of a system that is being 
developed. 

A domain-specific language (DSL) is a programming 
language that is designed to perform tasks and to solve 
problems in a particular domain, such as operating a power 
plant or processing launch vehicles. For example, UNIX® 
shell scripts are a good example of a DSL for data 
organization because they are very useful for taking user 
input and manipulating data in files. Although powerful and 
robust, UNIX® shell scripts are not very conducive for 
creating complex data structures, such as lists and trees, and 
most do not support object oriented design [5] . 

A DSL has been created by the LCS Application Services 
Product Group for developing test sequences of ground 
checkout and launch operations of Constellation vehicle 
elements [6]. Figure 4 shows the software functionality that 
was previously shown in Figure 3 for opening a valve, but it 
is now written in the new DSL that was created for the LCS. 
This example is a simplified snippet from a much larger and 
more complex DSL-based program that was recently 
developed as an LCS prototype user application. 

ft SEND THE PRIMARY OPEN COMMAND 

aend_command (diacrete ( "VLVl_PRI_OPEN_CHD" , "ON” ) ) 

ft VERIPY THE PRIMARY INDICATORS CHANGE APPROPRIATELY WITHIN 
ft THE REQUIRED TIME CONSTRAINTS 
if verify_within_voting (2, 

[lambda « read. VLVl_PRI_CLOSED_IND == OFF, 
lambda : read. VLV1_PRI OPEN_IND == ON), 

[-VLV1 PRI_CLOSBD_IND n 7 "VLVl_PRI_OPEN_IND"] , 

[8, 26]*, DIALOG, 

" VL vi_ P R I_CLOSED_ I ND and VLVl_PRI_OPEN_IND" ) > 0 : 

ft A FAILURE OCCURRED. GENERATE ERROR MESSAGE. 
oend_me □ a age ("VALVE1 PRIMARY COMMAND FAILED’’, 
SY61, WARNING) 

ft USE SECONDARY COMMAND & SECONDARY INDICATORS 
perform ( "OpenValvelSecondary" , [), BLOCKING) 

ft SUCCESS. GENERATE MESSAGE TO USER. 

oend_meooage ("VALVE1 OPENED SUCCESSFULLY" , SYS1, INFORMATION) 

Figure 4 - Typical example of new application software 
source code using a DSL 
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The DSL code that was created for the LCS uses keywords 
and functions that are familiar to the ground and flight 
system user, such as “send command”, “send message”, and 
“voted verify within”. The “voted verify within” scenario 
will now be explained briefly as it will be used later in 
numerous examples. 

In the spacecraft ground processing domain, a simple “verify 
within” operation takes a single measurement (e.g., a valve 
position indicator) and verifies that it changes to a specified 
or expected value (e.g., OPEN, CLOSED, ON, OFF, etc.) 
within a specified time period. A “voted verify within” 
operation is similar to the “verify within” operation, except 
that it takes multiple measurement parameters instead of just 
one and it also takes an argument for the total number of 
voted measurement parameters that must be true in order for 
the whole voted verify within operation to be true. 

This voted verification functionality is very useful in safety 
critical control systems that utilize a lot of redundancy or 
duplication of commands and/or measurements. A ground 
or flight system might contain three separate measurements 
that all give the state of a single end item, such as the 
position of a valve. However, the ground or flight system 
user might consider the valve to be successfully opened and 
operating within specifications if one of the three indicator 
measurements was failed and only two of the three actually 
indicated that the valve was open. This is a “2 of 3 voting” 
indicator scenario and is quite common in this domain. 

The DSL code encapsulates the programming details of the 
voted verify within operation and attempts to elevate the 
programming language to the abstraction and level of 
understanding within the ground and flight system users 
domain. Unfortunately, some software programming skills 


are still necessary to write application software using this 
new DSL. So the developers of the LCS investigated other 
ways to represent the application software and is currently 
developing a tabular specification format that uses the DSL 
keywords and functions that are familiar to the ground and 
flight system users. The tabular specification format, or 
tabular spec, allows most ground and flight system users to 
document how the application software is intended to 
function and requires little or no software programming 
knowledge or experience. 

Figures 5, 6 and 7 show small portions of application 
software tabular spec from the LCS prototype effort. The 
sample in Figure 5 demonstrates the same application 
software functionality that was previously shown in Figures 
3 and 4. It commands a valve to the open state and then 
looks for the appropriate valve position indicators within the 
appropriate time constraints. The sample in Figure 6 
configures the LCS to start monitoring the pressure in a tank 
and to react appropriately when the pressure goes below or 
above some specific thresholds. The sample in Figure 7 
sends a text message to the user console in order to notify 
the user of an important event. 

It is evident from these three simple tabular spec examples 
that software programming skills are no longer required to 
write application software in the LCS. Representing 
application software in this tabular spec format has many 
advantages. It is a high level semantic that is conducive for 
end users who are not software savvy, to create their 
applications themselves. This new representation of the 
application software is smaller in size and is also less 
complex than the prior representations which equates to a 
productivity increase by comparison. 


LINE 

ROUTINE IDSL API |OBJECT|S| 

DESCRIPTION MESSAGE 

LOVAL 

HI 

VOTING 

DURATION 

REACTION 

1 

# Routine sends primer/ OPEN commend end nets for appropriate indicators 







2 

OpenValvelPritnaty 

# Send pnmary OPEN commend 







3 


$eii4l_coitiiii4ii<l 

VLV1_PRI_0PEN_CMD 

Valvel Pnmary Open Command 

ON 





4 










5 


# Verify both pnmary indicators chanqe appropnateky <Mth>n appropriate lime durations, on failure call another routine to perform Secondary Open Command 

6 


verify within 

VLV1 PRI CLOSED IND 

Valvel Primary Closed Indicator 

OFF 


2 of 2 

8 sec 


7 


verify within 

VLV1 PRI OPEN IND 

Valvel Pnmary Open Indicator 

ON 


2 of 2 

26 sec 

OpenValve 1 Secondary 

8 

end 









9 











Figure 5 - Typical example of new LCS application software tabular spec - Opening a valve 


LINE 

ROUTINE 

DSL API lOBJECTlSl 

DESCRIPTION MESSAGE 

LOVAL 

HI 

VOTING 

DURATION 

REACTION 

41 

# Routine starts assert monA 

I 

1 

§ 

r 

I 

I 

I 

1 

% 

1 

1 

1 

3 






42 

Star tAirtoTankPi ess 

# Monitor for high pressure 







43 


assettconstiaint 

TANK PRESSURE 1 

Tank Pressure Indicator #1 

15 


1 of 3 



44 


•meit constraint 

TANK PRESSURE 2 

Tank Pressure Indicator 40 

15 


1 of 3 



45 


asseit constraint 

TANK PRESSURE 3 

Tank Pressure Indicator #3 

15 


1 of 3 


OpenVapoiizeiValve 

46 










47 


# Monitor for low pressure 







48 


asset tconstiaint 

TANK_PRESSURE_1 

Tank Pressure Indicator #1 


25 

1 of 3 



49 


assert constraint 

TANK PRESSURE 2 

Tank Pressure Indicator 40 


25 

1 of3 



50 


assert constraint 

TANK PRESSURE 3 

Tank Pressure Indicator 40 


25 

1 of 3 


CloseVaporizei Valve 

51 

end 
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Figure 6 - Typical example of new LCS application software tabular spec - Monitoring pressure in a tank 


LINE 

ROUTINE |DSL API 

OBJECTS 

DESCRIPTION MESSAGE 

LOVAL 

HI 

VOTING 

DURATION 

REACTION 

21 

# Routine notifies user of failure 








22 

OpenValvelEtioi 

# Send a failure message to the user 







23 


sen*! inessaye 


Unable to open Valvel 






24 

end 
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Figure 7 - Typical example of new LCS application software tabular spec - Sending a user a text message 
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The tabular spec also contains inherent tracing from user 
requirements to implementation and minimizes the learning 
curve for capturing application requirements and brings 
consistency to the process. It also improves the quality of 
the application requirements with a consistent, structured 
format. The use of a DSL along with this tabular spec 
allows the domain expert or end user to focus on solving the 
domain problem rather than focusing on the software. 

The LCS developers realize that this tabular spec format is 
limited in features and capabilities as compared to the prose 
programming approach shown in Figure 4, but many 
existing application software examples from the ground 
processing domain have already successfully been 
represented in this tabular spec format. Even if only half of 
the total user application software can be represented in 
tabular spec format, that equates to a significant 
improvement in cost, schedule and manpower necessary to 
develop, implement and maintain the LCS. Anecdotal 
evidence suggests that up to 80% of the existing Space 
Shuttle program user application software might be 
successfully represented in the new tabular spec format. We 
are currently investigating this estimate and hope to produce 
empirical data to further refine it. This level of applicability 
could translate into significant cost savings for the 
Constellation program which reuses some legacy Space 
Shuttle program elements, such as Solid Rocket Boosters. 

Problem Description 

The LCS developers needed a mechanism or tool to translate 
application software from tabular spec format into PLC code 
to execute on the PLC platforms out in the field. The LCS 
developers were tasked to investigate the possibility of 
manually and automatically creating the application software 
portion of the PLC code from the tabular spec 
representation. A portion of some legacy application 
software that performs the task of loading fluids into a tank 
was represented in tabular spec format by a team of NASA 
KSC ground system engineers. This representative sample 
tabular spec was used as the starting point for both the 


manual and the automatic PLC code creation process. 

This work was considered a prototype effort and was 
performed for the sole purpose of determining if it was even 
possible to automatically create PLC code from a high level 
representation of the application software. The tabular spec 
format (Figures 5, 6, 7) was chosen for this prototype effort 
over the DSL prose format (Figure 4) for multiple reasons, 
but mostly because representing user application software in 
the tabular spec format has many cost and schedule benefits 
over the DSL prose format. Also, the tabular spec format is 
simpler and more structured and should lend itself better to 
parsing and translation. 

In the LCS, the application software will be distributed 
between servers that are located locally in the control room 
and PLCs that are located remotely out in the field . This 
paper focuses only on the portion of the application software 
functionality that is expected to execute on the PLCs out in 
the field, and not the portion that is expected to execute in 
the control room. 


2. Application 

Manual Translation 

A few small executable sections from the previously 
mentioned tank loading tabular spec were selected for 
manual translation into PLC code. The first selection was 
made up of three subroutines, shown in Figure 8, that 
attempt to open a valve allowing fluid to flow in a pipe. The 
first subroutine attempts to open the valve using the primary 
command and response path. The second subroutine is 
called from the first if the valve fails to open. This second 
subroutine attempts to open the same valve using the 
secondary or backup command and response path. The third 
subroutine is called from the second if the valve fails to 
open again on the second attempt. This third subroutine 
generates an error message to the user. 


Program Name ValveOpenlmjSequence Prog Description This program demonstrates sending a command and verifying discrete indicators. Uses multiple routines with error paths 


LINE 

ROUTINE |DSL API | OBJECTS 

DESCRIPTION MESSAGE 

LOVAL 

HI 

VOTING 

DURATION 

REACTION 

1 

# Routine sends pnmary OPEN commend and waits lot appropriate indicators 







2 

OpenValvelPiimaiy 

# Send pnmary OPEN command 







3 


sendconiinand 

VLV1 _PRI OPEN CMD 

Vatvel Primary Open Command 

ON 





4 










5 


# Verify both pnmary indicators change appropriately within appropriate time durations, on failure calf another routine to perform Secondary Open Command 

6 


verify within 

VLV1 PRI CLOSED IND 

Valvel Primary Closed Indicator 

OFF 


2 of 2 

0 sec 


7 


veiHy within 

VLV1 PRI OPEN IND 

Valvel Primary Open Indicator 

ON 


2 of 2 

26 sec 

OpenVahralSecondaiy 

0 

end 









9 










10 

1 

1 

% 

| 

! 

i 

£ 

! 







11 

OpenV.ilvel Secondary 

# Send secondary OPEN command 







12 


send command 

VLV1_PRI_OPEN CMD 

Valvel Primary Open Command 

OFF 





13 


sendcomniand 

VLV1_SEC_SELECT_CMD 

Vatvel Secondary Select Command 

ON 





14 


send command 

VLV1_SEC OPEN CMD 

Valvel Secondary Open Command 

ON 





15 










I 16 


1 

I 

Si 

1 

1 

I 

w*hm appropnate time durations, on failure call another routine to generate a user message 

17 


veiify within 

VLV1 SEC CLOSED IND 

Valvel Secondary Closed Indicator 

OFF 


2 of 2 

8 sec 


10 


verify within 

VLV1_.SEC OPEN IND 

Valvel Secondary Open Indicator 

ON 


2 of 2 

26 sec 

OpeiiVatvelEnoi 

19 

end 









F20 










21 

# Routine notifies user of failure 








22 

OpenValvelEiiot 

# Send a failure message to the user 







23 


semi message 


Unable to open Valvel 






24 

end 









L* 











Figure 8 - First selected executable tabular spec section - Opening a valve with error paths 
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The functionality of all three of these subroutines was 
manually coded into PLC ladder logic 5 and tested using a 
field item simulator in order to verify the proper operation 
of the manually coded ladder logic. An Allen Bradley 
ControlLogix PLC was utilized along with Rockwell 


Automation’s RSTestStand ™ simulator software [7]. 

Figure 9 shows an example of some of the resulting 
manually translated PLC ladder logic. For brevity, only a 
very small portion of the PLC code is shown here. 



Figure 9 - Typical example of manually translated PLC code 
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programming languages besides ladder logic, but ladder logic was chosen 
for this prototype effort. 
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Tabular Spec Scenario 

Brief PLC Code Description of Translation Point 

discrete “send command” 

Latch to send ON command and Unlatch to send OFF command. 

analog “send command” 

Move an integer or float (real) value to a stimulus tag. 

discrete “set” command 

Latch to set ON and Unlatch to set OFF. 

analog “set” command 

Move an integer or float (real) value to a tag. 

all voted “verifywithin” 

A prerequisite rung with timers, then a failure rung if any (Boolean OR) timer 
finishes, then a success rung with Discrete (XIC/XIO) or Analog (GRT/LES) 
comparators in series (Boolean AND). 

any voted “verify within” 

Very similar to above. A prerequisite rung with timers, then a failure rung if all 
(Boolean AND) timers finish, then a success rung with Discrete (XIC/XIO) or 
Analog (GRT/LES) comparators in parallel (Boolean OR). 

“verify within” (non-voted) 

Simplification of voted case. Only one timer and only one comparator in the success 
rung. 

“verify” command 

Same as “verify within” cases, only without the timers. 

any voted “assertconstraint” 

Routine that executes continuously upon activation. Violation rung with Discrete 
(XIC/XIO) or Analog (GRT/LES) comparators in parallel (Boolean OR). 

all voted “assert constraint” 

Very similar to above. Executes continuously with a violation rung with Discrete 
(XIC/XIO) or Analog (GRT/LES) comparators in series (Boolean AND). 

“assert constraint” (non-voted) 

Simplification of voted case. Only one comparator in the violation rung. 

“remove constraint” command 

Just halts the “assert constraint” routine that executes continuously. 

“send message” command 

Pass a text string to a PLC System Message routine that was written manually as a 
System Software mini-layer on the PLCs. 

“send message id” command 

Same as “send message” case, only using message databank for parameters. 

“delay” command 

Rung with a timer. Halt execution of routine until timer finishes. 

“perform” command 

Start a PLC routine by setting the value of a routine sequencer. 


Table 1 - Translation points from tabular spec to PLC code 


Translation Points 

This manual process of conversion or translation from 
tabular spec representation to PLC ladder logic 
demonstrated that translation points or patterns existed 
between portions of the tabular spec and portions of the PLC 
ladder logic. Table 1 shows the translation points that were 
identified by this manual translation process. 

Using these translation points, a few representative samples 
of the manually coded PLC ladder logic were exported from 
the PLC coding integrated development environment (IDE) 
as plain text. This exported text was then converted by hand 
into plain text PLC code “libraries” with the intent that a 
future automatic tabular spec to ladder logic translation 
utility would use these PLC code libraries during its 
translation process. In this context, the PLC code libraries 
could also be considered as code templates. 

Figure 10 shows a small sample from the PLC code library 
that was created by this manual translation process. 

# Sends a discrete (ON/OFF) command 
< LI BRARY ob j ec t = " Di scr e t eSendCommand " > 

Ns 

XIC (< INSERT objects "ExecutingTag"/>) 

< INSERT object="OtlOrOtu"/> (<INSERT ob j e ct =■ Object Tag "/>) 
; 

</LIBRARY> 

Figure 10 - Typical example of PLC code library 


This PLC code library object is intended to be used 
whenever a discrete (or Boolean) command is sent in the 
tabular spec. The < insert object=-ExecutingTag-/> portion is to 
be replaced by the automatic translation utility with a 
Boolean PLC flag that tells the PLC that the routine that 
contains this ladder rung is supposed to execute. The 
< insert ob j ect = "ot loro tu" / > portion is to be replaced with an 
output latch object or an output unlatch object, depending on 
whether an “ON” command or an “OFF” command is being 
sent. The insert object=»objectT* g -/> portion is to be 
replaced with the name of the discrete commandable object 
that is intended to be commanded. After the automatic 
translation utility employs this PLC code library, a tabular 
spec line that looks like that shown in Figure 1 1 should be 
translated into some PLC code that looks like that shown in 
Figure 12. 


DSL API 

OBJECT(S) 

DESCRIPTION MESSAGE 1 LO VAL 

sen<l_comin.in<t 

VLV1 _PRI OPEN CMD 

Valvel Primary Open Command | ON 


Figure 1 1 - Tabular spec example of discrete ON 
command 


Primary Cmd Routine 
Executing [0] 

•send command’ API from spreadsheet 
Sends primary command to end item 

Valvel Primary Open 
Command 

MSID VI VI PR| OPEN CMD 
_ - i r ~ 

J C 


Figure 12 - Manually translated PLC code for discrete 
ON command 
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Figure 13 shows another small sample from the PLC code 
library that was created by this manual translation process. 

ft First line of a voted verify within section. 

ft This code seta up a timer for each of the voted objects. 

< LIBRARY object=" VotedVerifyUithinTimera" > 

N: 

XIC (<INSERT Objects "ExecutingTag" />) 

c 

<LOOP objects "TotalVoted"> 

< INSERT object = "XicXiol"/>(< INSERT objects "Ob jectTag" /> 
< INSERT objects"XicXio2"/>) 
TON (< INSERT objects" Time rTag" />, 

< INSERT object="TimerValue"/>,?) 

</LOOP> 

1 

; 

</LIBRARY> 

Figure 13 - Typical example of PLC code library 

This PLC code library object is intended to be used to set up 
a ladder rung with timers for an “all voted verify within” 
scenario in the tabular spec. The section of code library 
surrounded by the <LOOP object=-Totai voted- > and the </loop> 
is to be repeated by the automatic translation utility for 
every voted measurement contained in the voted verify 
within section of the tabular spec. Inside that repeated loop, 
the < insert object=-TinerTag"/> portion is to be replaced with 
the name of an instance of a timer object that is to be 
automatically created for every voted measurement. The 
< insert objects -Tinerv«iue"/> portion is to be replaced with 
the actual time value that the timer object will count to in 
milliseconds. After the automatic translation utility employs 
this PLC code library, a tabular spec line that looks like that 
shown in Figure 14 should be translated into some PLC code 
that starts like that shown in Figure 15. 

Automatic Translation 

After manually performing some representative samples of 
translation from tabular spec to PLC ladder logic, and after 
manually creating a PLC code library for each of the 
translation points that were contained in the samples, a 
prototype automatic translation utility was then developed. 
A limitation of this prototype translation utility is that it only 
translates tabular spec snippets that match the translation 
points that were identified during the earlier manual 


translation process. The translation capabilities of the utility 
will be expanded as more and more translation points are 
identified, translated manually, and then turned into 
additional PLC code libraries. 

Figure 16 shows the simplified process flow for translating a 
single “sendcommand” line from tabular spec to PLC code. 
The spreadsheet that contains the application software in 
tabular spec format is exported to plain text and is used as 
input to the translation utility along with the PLC code 
library. The translation utility processes these input files 
using program transformation steps. This creates an output 
file that is capable of being imported by the PLC coding 
IDE. 



Figure 16 - Flow of tabular spec to PLC code translation 


DSL API 

OBJECTS 

DESCRIPTION MESSAGE 

LOVAL 

HI 

VOTING 

DURATION 

veilfy within 

VLV1 PRI CLOSED IND 

Valvel Primary Closed Indicator 

OFF 


2 of 2 

8 sec 

veilfy within 

VLV1 PRI OPEN IND 

Valvel Primary Open Indicator 

ON 


2 of 2 

26 sec 


Figure 14 - Tabular spec example of an all voted verify within 


Next 3 rungs handle the -2 of 2' voted “VERIFY_WITHIN" lines in the spreadsheet 
The first rung executes the timers and then only one of the next 2 rungs will become true. 

valve 1 Closed Ind 

valve 1 Primary 

Primary Cmd Routine Closed indicator 

Executlng(O) MSID_VLV1_PR 


must go OFF within 8 
seconds 


l_CLOSEPJNO 

TON 



Timer On Deldy 
Timer TimerjO] 

™ cn — 

“(DN)— 



Preset 8000 




Accum 0 




valve i Pnmaryopen 
indicator 

MSID_VLV1 PRI_OPEN_IND 

■i'i 


Valve 1 Open Ind must 
go ON within 26 
seconds 

TON 


Timer On Delay 
Timer Tlmertl) 

Preset 26000 

Accum 122246 


KEN l 

DN l 


Figure 15 - Portion of manually translated PLC code for an all voted verify within 
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Perl, a widely used scripting language, was used for the 
prototype translation utility due to Perl’s regular expression 
and text processing capabilities, and also due to its rapid 
application development capabilities [8]. Figure 17 shows a 
short code snippet from the prototype translation utility. 


Rockwell Software’s RSLogix IDE was used to demonstrate 
that the output of the prototype translation utility could be 
imported into a PLC and executed without modification. 
RSLogix imports and exports a unique plain text project 
definition format, although the vendor is in the process of 
transitioning to an Extensible Markup Language (XML) 


if ($£oundLibrary eq "true**) { 

if ($verboaity >= $oomeDebug) { print {" Library snippet found: V" . $LibToParoe . "\"\n n ) ; ) 

$myTot Rout ineo = getTotRout ineaPromRoutineHame ($Rout ine, ^RoutineMap) ; 

if ($verbooitv >= $oomeDebug) { print ("Total Routines: ■" . $™yTot Rout ine s . "\"\n ") ; } 

$mvReoStart = getReeourceStartPromRout ineName ( $Routine, «>Rout ineMap) ; 

if ($verboaitv >= $oomeDebug) { print ( "Start ing Resource Rum: \" " . $myReoStart . "\"\n") ; } 

$LibTo Parse a/<LIBRARY object=\"RoutineAndSequenceStarter\" »<[.]♦) /$l/; 

$LibToParoe =~ a/« INSERT object =\ H SequencerTag\ ,, \/>/Sequencer [$CurrentSeqId] / ; 

$LibToParoe =- s/<LOOP object=\ "SuccesoTagoN" >([.]*) /$l/ ; 

for (my $ct r=$n.yReoStart ; $ctr < ($myResStart ♦ $myTot Rout ine s) ; $ctr + + ) { 
if <$ctr < ($nyReoStart ♦ $ myTo t Rout ine s - 1)) { 

$LibToParoe o/([ A \n]*) (< INSERT object=\"Succeo3Tag\' , \/>) ( [ A \n] ♦) /$lSucceoa [$rtr] $?\n$l$2$i/ ; 

else { 

$LibToParse =~ o/ ( [ A \n] *) (<INSERT object = \"SucceosTag\ , *\/>) ( C\n] ♦) /$lSucceso [$ctr] $1/ ; 

} 

) 

$LibToParoe =- of <[.]♦) <\/LOOP>/$i/ ; 

$LibToParse =~ s/<INSERT object=\’ , ExecutingTag\"\/>/ Executing [$CurRout ineld] /; 

$LibToParce =- of< INSERT obj ect=V*Count erTag\ "\/>/Counter I$(^irRout ineld] / ; 

$LibToParse of ( [ . ] ♦ ) <\/LIBRARY>/$l/ ; 

$LibToParoe =- c/\n//g; 

$LibTo Parse =- a/\t//g; 

$LibToParoe of, ]/l/g; 

Figure 17 - Sample of translation utility perl code 


The syntax for using the translation utility is as follows: 

> TabularToPlcUtility-proto.pl [-i in] [-o out] 


Since the PLC code library was not expected to be changed 
or switched out by the user, it was not deemed necessary or 
useful to include it as a command line argument during the 
prototype phase of the project. Figure 18 shows the 
translation utility being used during the prototype phase of 
the project. 



import and export spec format [9]. XML is a specification 
for a widely accepted general purpose markup language that 
is commonly used to share structured data between different 
information systems [10]. PLCOpen, a PLC open standards 
organization, has created an XML-based specification for 
the exchange of PLC programs, libraries, and projects 
between PLC development environments [11]. However, 
most of the major PLC vendors have not adopted this open 
standard in favor of their own import/export approaches, 
which many feel are more powerful and robust. 

After the prototype translation utility was developed, the 
same set of executable tabular spec sections from the tank 
loading application that were used for manual translation 
were selected for automatic translation into PLC code, in 
addition to a few other executable examples of tabular spec. 
Figure 19 shows a small tabular spec subroutine that 
attempts to open a valve using the primary command and 
response path. This same subroutine was used earlier in the 
manual translation section of the paper. Figure 20 shows the 
PLC code that was automatically translated from this 
particular tabular spec subroutine. 


Figure 18 - Example of translation utility in use 
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This automatically translated PLC code looks almost exactly 
like the manually translated PLC code shown earlier in 
Figure 9, with the addition of tabular spec line numbers in 





Figure 19 - Portion of tabular spec to be automatically translated into PLC code 


Execution Sequencer 
0 starts in 

Open Valve 1 Primary 

EQU 


Equal 

Source A Sequencer^ 
0 

Source B 1 


Open valve 1 Primary 
routine 
Success{0] 

CuD 


Openvalve 1 Secondary 
routine 
Success! 1] 

(U) — 


OpenValvel Error 
routine 
Success(2] 

CUD 


OpenValvel Primary 
routine 
FaiiurefO] 

JJ, 


OpenValve 1 Secondary 
routine 
FaHurefl) 

CuD 


OpenValvel Error 
routine 
Failure(2) 

CuD— 


Open Valve 1 Pnmary 
routine 
Executing(0] 

co 


OpenValve 1 Primary 
execution counter 

CTU — 


Count Up 
Counter 
Preset 
Accum 


-CcuD 

CountertOJ K.DN 
0 
0 


Openvalve 1 Primary 
routine 
ExecutingfO] 


Sets the value of a Discrete FD (or PLC Tag) (from app line 3) 


-3 E- 


Valvel Primary Open 
Command 

FD_VLV1_PRI OPEN_CMD 


Cl> 


Vertfy both primary indicators change appropriately within appropriate time durations, on failure can another routine to perform Secondary Open Command 
Next 3 rungs handle voted venfy wtthin First rung executes timers, then only one of following 2 rungs will become true (from app lines 6-7) 

FD 

VLV1PRICLOSEDJND 
(Valve i Pnmary 
Closed Indicator) 

Openvalve 1 Pnmary Valve 1 Primary must go OFF within 8 

routine Closed Indicator sec 


ExecutingfO] 

3 E— - 


FD VLV1 PR| CLOSED IND 

— — =-TE- " 


-TON- 


Vatvel Primary Open 
Indicator 

FD_VLV1_PRI OPENJND 

§/p 


Timer On Delay -fEN>- 

Timer TimerlO] -<DN>- 

Preset 8000 

Accum 0 

FD VLV1_PR]_OPEN_IND 
(Valve 1 Prtmary Open 
Indicator) must go 
ON within 26 sec 



OpenValvel Prtmary 
routine 
Executing(0] 

3 F 


IT any verify within falls, we set the failure nag and switch sequencer execution to the failure state 

FD 

VL V 1 PRICLOSE D_l ND 
(Valve 1 Prtmary 
Closed indicator) 
must go OFF within 8 
sec 
1DN 


Tlmer fO] D 


Openvalve 1 Prtmary Openvalve 1 Prtmary 

routine routine 

Faiiure(0) Executtr»g(0] 

CO CUD- 


Execution Sequencer 
0 starts in 

Openvalve 1 Pnmary 



Openvalve 1 Prtmary 
routine 
Executing(0] 

3F 


Open Valve 1 Prtmary 
routine 
Exeq jt jng(0] 


FD 

VLV1_PRI_OPEN_IND 
( Valve 1 PrtmaiyOpen 
indicator) must go 
ON within 26 sec 
Tlmw t jJ.DN 

if all vertfywtthin’s succeed, we set the success Tlag and continue to a normal routine exit 

Valve 1 Prtmary Valve 1 Prtmary Open OpenValvel Prtmary OpenValvel FMmary 

Closed Indicator indicator routine routine 

FDVLV 1 PRI CLOSEDJND FD_VLV1_PRI OPEN_IND FallurefO] Success{0) 

^3 E 00 


End of routine Reset command sequencer to the wait state (from app line 8) 


OpenValvel Pnmary 
routine 
Success{0] 

ougcpj 


Open Valve 1 Prtmary 
routine 
Executlng(0) 

CU> 


Execution Sequencer 
0 starts in 

Openvalve 1 Pnmary 



Figure 20 - Automatically translated PLC code from tabular spec portion shown in Figure 19 
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the rung comments of the automatically translated PLC 
code. The execution behavior of the manually translated 
code and of the automatically translated code was exactly 
the same. The similarity between the two was no accident. 
This code similarity is inherent to the process of manually 
creating PLC code libraries or code templates for use by the 
automatic translation utility. The authors recognize there 
are tradeoffs here. The manually and automatically 
translated PLC code may not be the most compact nor 
efficient. However, we feel that it is very important that the 
automatically translated PLC code be readable and 
understandable by PLC programmers. This strategy favors 
life-cycle costs as long as performance requirements 
continue to be met. 

Some readers may ask why we would need to keep any PLC 
programmers on staff if we are automatically “generating” 
PLC code. There are many reasons: 

(1) The resulting PLC code will have to be tested 
functionally and also for performance. 

(2) The PLC programmers will be needed to troubleshoot 
and fix any problems that are found. 

(3) Assuming that problems are found and corrected, those 
corrections will have to be back-implemented into the 
automatic translation utility and into the PLC code 
libraries. 

Also, there may be PLC code needed by the control system 
that cannot easily be automatically translated. For example, 
layers of PLC code that are deemed as “system software” 
that are used to interface between the application software 
layer and the rest of the LCS subsystems and components do 
not have to be written nor maintained in the domain of the 
ground and flight system user. Thus, these layers can be 
written directly in low level PLC code by experienced PLC 
programmers. These system software layers along with 
some other PLC code will probably need to be merged with 
the automatically translated PLC code. The automatic 
translation utility could be modified to perform this merge 
operation, or a separate utility could be created specifically 
for the merge task. 

Return On Investment 

Automatic application code generation from a high-level 
tabular spec has many economic advantages. In large 
systems, this technique helps to prevent quality and 
maintainability problems; it automates recurring software 
development steps; and it allows shorter product 
development time. The ability to represent the software 
design using a DSL that is oriented more towards the 
problem space than the solution space also contributes to 
these economic advantages. Also, miscommunications and 
misunderstandings between the requirements of the domain 
expert and the code implementation of the software 
developer are reduced in this process. In addition, code 


consistency is increased and maintenance costs are 
decreased. [4], [12], [13] 

Assuming that the automatic translation utility is tested 
thoroughly and formally validated and certified after 
development, the use of such a tool during the LCS 
development and future maintenance phases will increase 
the reliability and quality of the code that resides in the 
PLCs. In addition, a certified tool such as that described 
here will also increase the verification and validation (V&V) 
pedigree of the final PLC code because much of it will be 
generated by a certified tool as opposed to being generated 
by error prone human programmers 6 . This is very important 
for any software system, but even more so for safety critical 
software systems. 

Using an automatic translation utility, the LCS will contain 
identical translations of identical portions of application 
software across different ground systems. This level of code 
consistency is difficult or impossible to obtain when 
multiple human programmers, or even one single human 
programmer is in the loop. Even when following approved 
and published coding standards, each coder has his or her 
own style and preferences as to how to solve each problem 
that is set before them. Even a single coder will sometimes 
solve the same problem differently on different days. 
Inconsistency in code can become a burden during 
troubleshooting efforts, during maintenance activities, and 
especially during the future upgrade process. 

In our domain, the potential exists for very large tabular 
spec representations of application software and the 
potential also exists for significant repetition of similar tasks 
and functions within those potentially very large tabular 
specs. The automated production of large amounts of 
repetitious and/or tedious PLC software is expected to be a 
significant cost and schedule savings in the overall LCS 
project development life-cycle. 

There are also payoffs down the road after the LCS is 
operational. Operations and Maintenance (O&M) costs of 
the application software residing on the PLCs could be 
reduced by this process for system changes and maintenance 
activities. Not only do these tools and processes have great 
potential to save the LCS project both cost and schedule, but 
the use of these tools and processes has the potential of 
making a better product than could be made manually. 

One problem worth noting during this prototyping process 
was resistance and skepticism from some members of the 
PLC programming community. Since many PLC 
programmers generally have an electrical or electronics 
design background instead of a software engineering 
11 

6 Please note that the authors are both error prone human programmers 
ourselves and we value the numerous benefits of humans in the loop. 
However, we also value the numerous benefits of letting computer 
programs handle tedious and repetitious tasks, at which human 
programmers are more prone to make errors. 
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background, the notion of automatic code generation often 
appeared foreign and the benefits of said technology were 
not completely obvious to them. It is hoped that our 
proposed solution will help the PLC programmers become 
more aware of some software engineering and V&V 
principles and their benefits. 

Related Work 

Automatic code generation and automatic code translation 
technologies have been in use in the Software Engineering 
industry for a long time. Literature reviews by the authors 
turned up only a few examples where these techniques and 
technologies were being used to automatically generate PLC 
code. 

The U.S. Navy (Naval Surface Warfare Center, 
Philadelphia) has developed PLC based Machinery Control 
Systems (MCS) for use on various ships. Much of the PLC 
code, along with the SCADA display code in MCS is 
automatically generated from information in a hardware and 
measurement configuration database, however the actual 
machine control logic (i.e., application software) is written 
entirely by hand. The generated PLC code is automatically 
integrated with the machine control logic [14]. 

Semantic Designs, Inc. has developed an enterprise level 
productivity suite called the Design Maintenance System 
(DMS) ® Software Reengineering Toolkit. This program 
transformation tool is capable of translating very large high 
level mechanical process specifications or a DSL into highly 
optimized PLC ladder logic. The tool is designed to use 
several small and relatively simple layers of translation 
stacked on top of one another. This multi-layered 
transformation tool design is less brittle than other program 
transformation tools that have to do more work and perform 
more complex transformations all at one time [15], [16]. 

This DMS ® toolkit appears capable of producing efficient 
PLC code from our tabular spec format but was not chosen 
for the LCS prototype effort due to the added cost and 
schedule impact of needing to engineer new transformation 
layers and domain specific knowledge between our new 
tabular spec format and transformation layers that already 
exist in the tool. Also, to a lesser extent, highly optimized 
PLC ladder logic was not as much of a priority on this 
project as was human readable and understandable PLC 
ladder logic. 


3. Conclusions and Future Work 

This work has successfully demonstrated that a process and 
a software tool are capable of generating executable PLC 
code from a high level specification representation of a 
safety critical control system. This process includes some 
manual work to find translation points and to create PLC 
code libraries. However, that up front and one-time manual 
effort is overshadowed in the end by the automatic 
generation of repetitious and tedious functionality that 
would be difficult and error prone to perform manually. 

Such a process and tool increases the quality, reliability, 
maintainability, and verification/validation pedigree of the 
PLC code over that which is coded manually. It also 
provides a high level of PLC code consistency and could 
even reduce operations and maintenance costs for the 
control system after it is deployed. 

Follow-on phases of development of the automatic 
translation utility should include most, if not all, of the 
following tasks: 

(1) Prototype and demonstrate manual and automatic 
translation into mixed PLC programming languages as 
appropriate (e.g., function block diagram, sequential 
function chart, structured text, instruction list). 

(2) Represent as much of the LCS application software in 
the tabular spec format as possible without 
overcomplicating the tabular spec format. 

(3) Manually implement the remaining translation points 
and any newly discovered translation points along with 
the matching PLC code libraries. 

(4) Add code to the translation utility to recognize and 
handle the new translation points along with the new 
PLC code libraries. 

(5) Test and certify the translation utility for automatic 
generation of safety critical PLC control logic in the 
LCS at KSC. 

(6) Extend the translation utility as necessary to generate 
PLC code that can be imported by various PLC vendor 
products. 
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